1. Field of the Invention
The invention relates generally to managing flows for a reservation protocol and addressing security issues that exist in current Internet Protocol (IP) telephony products. More particularly, the invention relates to a technique for pre-allocating an aggregated reservation protocol session and thereafter sharing the reservation protocol session among multiple individual application sessions by multiplexing the multiple individual application flows thereon while additionally providing for selective end-to-end encryption.
2. Description of the Related Art
The consolidation and transfer of voice and voice-band data (e.g., fax and analog modems) with data services over public packet networks, such as the Internet, is rapidly gaining acceptance. However, significant work remains in the area of enhancing the quality and ensuring the security of such services. One potential technique for improving the quality of voice over Internet Protocol (VoIP) calls involves the use of a bandwidth reservation protocol to communicate per-flow requirements by signaling the network. Typically, however, bandwidth reservation protocols require per-flow state information to be maintained at each intermediate node between the initiator and the prospective recipient. As a result, in a VoIP network relying on such bandwidth reservation protocols, scalability becomes an issue since each VoIP call reservation requires a non-trivial amount of ongoing message exchange, computation, and memory resources in each intervening node to establish and maintain the reservation.
An example of a particular bandwidth reservation protocol that illustrates this scalability problem is the Resource Reservation Protocol (RSVP). RSVP is an Internet Protocol-(IP) based protocol that allows applications running on end-stations, such as desktop computers, to communicate per-flow requirements by signaling the network. Using RSVP, the initiator of a VoIP call transmits a Path message downstream to the prospective recipient. The Path message causes state information, such as information regarding the reverse path to the initiator, to be stored in each node along the way. Subsequently, the prospective recipient of the VoIP call initiates resource reservation setup by communicating its requirements to an adjacent router via an upstream Resv message. For example, the prospective recipient may communicate a desired quality of service (QoS), e.g., peak/average bandwidth and delay bounds, and a description of the data flow to all intervening routers between the call participants. Additionally, after the reservation has been established, participating routers must continue to exchange periodic status and control messages to maintain the reservation. Consequently, processing and storage overhead associated with reservation establishment and maintenance increases linearly as a function of the number of calls. For further background and information regarding RSVP see Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., “Resource Reservation Protocol (RSVP) Version 1 Functional Specification,” RFC 2205, Proposed Standard, September 1997.
A proposed solution to RSVP's scalability problems can be found in F. Baker et al., “Aggregation of RSVP for IPv4 and IPv6 Reservations,” Internet Draft, March 2000. However, the proposed solution requires a modification to RSVP, which would result in changes to router software. Additionally, the proposal does not use RSVP end-to-end, but rather uses Diff-Serv in the core. It may also require changes to other routing protocols like OSPF and IS-IS. Finally, it appears that there may also be additional burdens on network administrators to make the aggregation scheme work.
With regard to security, a technique for achieving router-to-router privacy is router-based encryption (RBE). However, this solution is neither scalable nor flexible as it encrypts every packet that is transmitted through the router and the router doesn't have any information to map packets to a particular voice call to allow for selective encryption. In light of the foregoing, what is needed is a less invasive technique for managing application flows that require real-time response, such as flows associated with VoIP services, and addressing scalability and flexibility issues associated with bandwidth reservation protocols and RBE. It is also desirable to minimize changes to the particular bandwidth reservation protocol employed and existing router software.